Applications for enabling message transfer between diverse message sources are becoming common. FIG. 1 is an illustration of a prior art inter-process messaging system such as the SmartSockets 5.5 publish-subscribe messaging infrastructure provided by Talarian Corporation™. SmartSockets enables clients to publish messages to a server cloud that relays the message to all interested client subscribers. The publishing client is responsible for ensuring that a message being published is created and injected into the cloud for delivery in conformance with the formats and protocols specified by the SmartSockets messaging infrastructure. In FIG. 1, the client process 108 is a dual homed ‘bridge’ client. Client module 108.3 interacts with a message source 106 using source specific protocols of interaction; module 108.2 performs any message translation between the source specific message format and SmartSockets specific message format, and module 108.1 communicates with other client processes through the SmartSockets messaging infrastructure. In communicating with other clients, each message source 106 receives a message from its own message source (through module 108.1) translates the message into the SmartSockets canonical message format (through module 108.2) and injects the message into the SmartSockets delivery system (through module 108.3) for delivery to the interested subscriber clients.
This system, although efficient, still requires each message source 106 to interact with the SmartSockets cloud for communication with other message sources 106 through bridge client processes 108. Currently, each message source 106 must reinvent module 108.1 for each new source type. Since, typically, the implementation of module 108.1 is standard across all message sources 106, this implies a duplication of prior effort for each new message source type.
Moreover, each module 108.1 must subscribe to the server cloud 100 independently for its message source 106. Therefore, when the server cloud 100 needs to deliver a message to message sources 106, it must route a copy of the message to each module 108.1 that subscribed to the message. Thus, the server cloud 100 bears the burden of transmitting a number of copies of each message in order to reach the different message sources 106. This could result in excessive use of the network bandwidth, thereby effectively restricting the scale of the deployment of such an application.
Typically, messaging systems such as SmartSockets perform routing of messages based on control information present in a published message. In the case of SmartSockets, when a client publishes a message, it specifies the destination subject of the message. This subject is present in the control block of the message when received by the server cloud 100. The server cloud 100 determines the interested subscribers by looking up the list of client processes 108 that have registered interest in the subject. The server cloud 100 does not inspect the data block of the message in order to perform routing calculations. In current implementations, if a message must be dispatched from a message source 106 to various heterogeneous message sources based on the content of the message, the message first needs to be routed to a application routing module 104 that determines the ultimate destinations of the message (using some application specific knowledge), and routes the message back through the server cloud 100 to the ultimate recipients of the message. Thus, each publication of a message requires the use of the server cloud 100 for content-based switching, which also increases bandwidth demands on the network. An improvement to the current system would be to enable content-based message routing without requiring a message to be transferred more than once (if at all) to the server cloud 100.
Therefore, an intra-process message switching framework is needed that enables the easy addition of different message source types to a switching environment, provides local content-based switching, and enables lower cost scalability for a network.